gh-152384: pixi-packages: use flags to define variants#152385
gh-152384: pixi-packages: use flags to define variants#152385lucascolley wants to merge 12 commits into
flags to define variants#152385Conversation
| - `freethreading` | ||
| - `asan`: ASan-instrumented build | ||
| - `tsan-freethreading`: TSan-instrumented free-threading build | ||
| - `tsan_freethreading`: TSan-instrumented free-threading build |
There was a problem hiding this comment.
I think it makes sense to remove the - from this variant name, given that it is invalid in the flags field: https://conda.org/learn/ceps/cep-0045#repodata-record-syntax
There was a problem hiding this comment.
seems fine to me, I think you and @crusaderky are just about the only users of these builds so far for what its worth
| run_exports: | ||
| noarch: | ||
| - python | ||
| weak: | ||
| - python_abi ${{ version }}.* *_${{ abi_tag }} |
There was a problem hiding this comment.
we could also define flags on python_abi and perhaps not need to rely on abi_tag as much? But I suppose we still want to keep abi_tag around at least while conda-forge does?
EDIT: can probably leave this for a follow-up and open an issue
|
@StanFromIreland this goes some way towards making the version update situation better by reducing duplication in the variant definition |
| openssl: | ||
| - '3.5' |
There was a problem hiding this comment.
ref. prefix-dev/pixi#6460 (comment) @h-vetinari, I wonder whether there is a better way to do this by pulling in (some of?) https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml
There was a problem hiding this comment.
obviously you could download the current pinning file, yaml-load it and extract the openssl pin, but that's perhaps more complexity and dynamism than justified - an argument could be made that openssl is special enough to handle it separately... and although pins have a habit of going stale, staying on an LTS version probably makes sense here.
conda-forge will probably migrate to openssl 4 in the fall, but since AFAICT python has no other dependencies that are themselves openssl-dependent, this should not cause any conflicts (except in larger environments with the most recent builds, but that's not really relevant for the ASAN stuff).
There was a problem hiding this comment.
obviously you could download the current pinning file, yaml-load it and extract the openssl pin, but that's perhaps more complexity and dynamism than justified
an idea was floated at some point that variant configs themselves could be packaged as conda packages and Pixi could consume them that way. Not sure if anyone has thought about that recently.
There was a problem hiding this comment.
I mean, conda-forge-pinning is exactly that package. You'd still have to go parse the yaml though. 🤷
|
The CI failure looks unrelated but before this PR can be merged it's going to need a NEWS entry. Can you add one? |
|
I've updated this branch from |
|
news added |
|
@ngoldbaum @kumaraditya303 any remaining concerns from your side? I think we can merge and patch up any more changes in a follow-up, this seems to be an improvement on the situation in |
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
Co-authored-by: Isuru Fernando <isuruf@gmail.com>
ngoldbaum
left a comment
There was a problem hiding this comment.
What happens if someone doesn't provide a variant flag? Which one is selected? None? Is there a good error? Should this be explicitly mentioned in the readme?
I left some more comments inline.
| - expat | ||
| - if: linux and "san" in variant | ||
| then: | ||
| - libsanitizer |
There was a problem hiding this comment.
Is this still needed now that we're using clang everywhere?
There was a problem hiding this comment.
Okay yeah, I presume it is GCC-specific and thus not needed.
| openssl: | ||
| - '3.5' | ||
|
|
||
| c_compiler: | ||
| - clang | ||
| c_compiler_version: | ||
| - 21 | ||
| cxx_compiler: | ||
| - clangxx | ||
| cxx_compiler_version: | ||
| - 21 |
There was a problem hiding this comment.
can we add comments explaining these pin choices?
There was a problem hiding this comment.
@kumaraditya303 how would you explain when these need to be updated, and where to look for the new versions?
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
Good catch. I think we may want to use |
cc @wolfv @baszalmstra @jaimergp I'm very excited about this PR!
pixi.toml#152384